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ABSTRACT 

A network comprised of a terrestrial site, a 
constellation of three GEO satellites and a LEO 
satellite is modeled and simulated. Continuous 
communication between the terrestrial site and the 
LEO satellite is facilitated by the GEO satellites. The 
LEO satellite has the orbital characteristics of the 
International Space Station. Communication in the 
network is based on TCP/IP over ATM, with the 
ABR service category providing the QoS, at OC-3 
data rate. The OSPF protocol is used for routing. We 
simulate FTP file transfers, with the terrestrial site 
serving as the client and the LEO satellite being the 
server. The performance characteristics are 
presented. 

INTRODUCTION 

The International Space Station (ISS) is a LEO (low 
earth orbit) satellite which needs continuous 
communication with a terrestrial location so that 
services such as communications, tracking, telemetry 
and data acquisition can be provided. An extensive 
worldwide network of tracking and communication 
ground stations could provide this type of service. 
Since each ground station can communicate for very 
brief periods of time when the ISS is in line of sight, 
an elaborate terrestrial network of ground stations is 
necessary for global coverage [1]. The cost of 
maintaining, operating and upgrading this 
worldwide network is prohibitive. 

An alternate approach to facilitate communication 
between the terrestrial location and the ISS is to use 


a constellation of GEO (geosynchronous earth orbit) 
satellites. The Tracking and Data Relay Satellite 
System (TDRSS) used by NASA represents such a 
system [2]. The TDRSS consists of three GEO 
satellites and a ground terminal facility located at 
White Sands, New Mexico. The system can transmit 
and receive data, and track a LEO user spacecraft for 
100 percent of its orbit. 

In this paper, we consider a constellation of three 
GEO satellites, with orbital characteristics similar to 
the TDRSS satellites, which can provide 100 percent 
global coverage. Unlike the TDRSS satellites, which 
are bent-pipe systems, the GEO satellites in this 
paper function as routers in a network. Our GEO 
satellites are also assumed to have inter-satellite 
links. A LEO satellite, such as the ISS, can 
communicate with the White Sands Ground 
Terminal (WSGT) via the GEO constellation [3]. 
Our objective in this paper is to determine the 
performance characteristics for communication 
between the ISS and the WSGT, using the GEO 
constellation. The communication is based on 
TCP/IP over ATM at OC-3. We present a 
comprehensive set of simulated performance 
characteristics -- throughput, end-to-end delay and 
server utilization — for a range of FTP file sizes. 

SATELLITE NETWORK 

The network consists of a ground terminal at the 
White Sands Ground Terminal (WSGT), White 
Sands, New Mexico; three GEO satellites which 
provide worldwide coverage and the International 
Space Station in a LEO orbit. The WSGT is 



responsible for the command, telemetry, tracking, 
and control of the GEO constellation and the ISS. 
The three GEO satellites, GEO-1, GEO-2 and GEO- 
3 are positioned over the Equator at 41° West, 275° 
West and 174.3° West longitude, respectively. 
These satellites are at an altitude of 22,300 statute 
miles (35,888 kilometers) and orbit 
geosynchronously. The GEO-1 satellite is in direct 
line-of-sight communication with WSGT. The 


simulation of the ISS, which is a LEO satellite, is 
based on the following orbital characteristics: semi- 
major axis = 6734.32 km, eccentricity = 0.0014064, 
inclination = 51.66°, right ascension of the 
ascending node = 243.89°, mean anomaly = 222.30° 
and argument of perigee = 137.91°. The network is 
illustrated in Figure 1 



The ISS communicates with the WSGT through the 
GEO satellites. The topology is such that the WSGT 
communicates solely with GEO-1. The GEO-2 and 
GEO-3 satellites can communicate directly with 
GEO-1, but not with each other. The ISS 
communicates with the closest GEO satellite. All 
communication in the network between the ISS, the 
GEO satellites, and the WSGT is at OC-3 (155 
Mbps). 

NODE ARCHITECTURES 

The node architectures of the terrestrial client, GEO 
router and the LEO server are depicted in Figure 2. 


The WSGT and the LEO satellite communicate 
using a client-server paradigm of interaction. The 
LEO server application waits passively for contact, 
while the client initiates communication actively. 
The node architecture of the terrestrial site consists 
of the application-level FTP client using TCP/IP 
over ATM. The ATM layer uses the ABR (Available 
Bit Rate) service categoiy. The OSPF (Open Shortest 
Path First) protocol is used for routing. The node 
architecture of the LEO is complementary to the 
terrestrial client, and has the application-level 
server. The three GEO satellites function as routers 
and their node architectures are comprised of IP over 
ATM, with OSPF being again used for routing. 






TCP/IP OVER ATM 

The TCP layer implements connection-oriented, 
reliable, byte stream transport using the potentially 
unreliable datagram service provided by the IP layer 
[4]. TCP is used to establish and terminate 
connections using three-way handshake protocols. 
Sliding window based flow control is used to prevent 
the transmitter from overwhelming the receiver with 
data. Reliability on an end-to-end basis is achieved 
by using acknowledgements. The retransmission 
time-out (RTO) is dynamically varied using 
Jacobson’s algorithm. To avoid the retransmission 
ambiguity problem, Kam’s algorithm is used. For 
congestion avoidance and control, the slow-start 
algorithm is used. The silly window syndrome is 
avoided using Nagle’s algorithm. 

The IP layer is a connection-less network protocol 
which enables the integration of heterogeneous 
networks. It provides an unreliable datagram service. 
Routing across multiple networks is the 
responsibility of the IP layer. The IP layer allows 
data to be interpreted consistently as they traverse 
the network. 

The ATM is a streamlined protocol with minimal 
error and flow control features, which reduces the 


number of overhead bits for each cell and therefore 
the overhead involved in the processing of each cell 
[5]. This combined with the fixed-size cells of ATM 
enables it to operate at high data rates. The ATM 
layer provides connection-oriented, in-sequence, 
unreliable, and guaranteed quality-of-service cell 
transport. The ABR service category of ATM is 
intended for bursty traffic sources whose bandwidth 
range is known approximately. An application using 
ABR specifies the minimum cell rate (MCR) 
required and the peak cell rate (PCR) at which it will 
transmit cells. The network then allocates resources 
to ensure that all ABR applications receive at least 
their MCR capacity. ABR is the only service 
category in which the network provides explicit 
feedback to the sources, asking them to reduce the 
transmission rate in the presence of congestion and 
thus enabling the fair allocation of resources. 

RESULTS 

To investigate the performance of TCP/IP over ATM 
using ABR in a constellation of GEO satellites, we 
simulated file transfers using FTP. The requests for 
transfers are generated by the client at WSGT using 
a Poisson distribution with a mean of 5 requests per 
hour. Each request results in one TCP session, 
which transfers the file from the server on the ISS to 




the client. The average size of the files is modeled 
using a normal distribution. Results are presented 
for a range of means: 60 KB, 300 KB and 1500 KB. 
The simulation results are for one-half day (43,200 
seconds) of operation of the satellite network for the 
indicated file sizes. Since the orbital period of the 
ISS is 91.66 minutes, these simulations will involve 
at least 7.86 orbits. 

In our simulations, we monitored the number of FTP 
requests submitted to the transport layer by the 
application layer of the client, and the corresponding 
number of FTP responses received by the application 
layer of the client. As both plots are nearly identical, 
Figure 3, we conclude that although the ISS is 
circumnavigating the earth in its orbit, the satellite 
network is functioning so as to allow continuous 
communication from the ISS to the terrestrial client 
even if there is no line-of-sight communication. 




Figure 3 


The conformity of the plots indicates that for every 
request sent by the client, a response follows shortly 
thereafter. This simulation is for 6,000 seconds, 
which is adequate time to simulate a single LEO 
orbit of 5,499.6 seconds. Additionally, we examined 
the end-to-end (ETE) delay, which is the time from 
the transmission of a request from the FTP 


application in the client to the time a response packet 
is received by the client. For this test we used a high 
mean file transfer rate of 10 files per hour and a 
small mean file size of 5 KB. The ETE delays were 
of the order of 200 ms, approximately the round-trip 
time delay in transmitting a message and receiving a 
response from a geosynchronous satellite. Figure 4 
is a plot of the ETE delays in the scenario just 
described, for one-half day of operation (43,200 
seconds). 
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Figure 4 


The fact that the server was utilized only for about 
25,000 seconds was determined by the number of file 
transfers, which is a random variable, and the file 
sizes, which is also a random variable. The plot of 
end-to-end delay is oscillatory in accordance with the 
fact that the elliptical orbit of the ISS is also 
oscillatory. Points on the curve which are minima 
correspond to those times in the simulation when the 
ISS is closest to the GEO-1 satellite which 
communicates directly with the client. After the 
server stops transferring files at approximately 
25,000 seconds, for the remainder of the simulation, 
the end-to-end delay is determined by the rate at 
which the client processes the accumulated files in 
its queue and hence the essentially constant nature of 
the delay. Any deviation from a constant end-to-end 
delay is not due to the randomly chosen file transfer 
sizes, which are centered about the mean; but it is 
due to the propagation delay through space. 

The throughput represents the average number of 
bits successfully received or transmitted by the 
receiver or transmitter channel, as the case may be, 
per unit time in bits per second. At various points in 
time, the throughput is essentially the running 
average from the start of the simulation up to that 
point. The throughput for the communication path 
consisting of the LEO server, GEO-3 satellite, GEO- 
1 satellite and the terrestrial client at WSGT is 






shown in Figure 5. In Figure 5(a), the throughput 
shown is for communication between the transmitter 
on the LEO server and the receiver on the terrestrial 
client for 60 KB files. This throughput is determined 
by the frequency of the requests for file transfers, the 
average size of each file and the data rate of the 
channel. As expected, the throughputs of the LEO 
transmitter and client receiver are almost identical, 
and the client receiver throughput is offset from the 
LEO transmitter throughput due to the propagation 
delay. Also, the client receiver throughput is slightly 
more than the transmitter throughput because the 
client receives duplicate packets from the GEO-2 
satellite. In Figure 5(a), the sharp increases in 
throughput correspond to those periods when the 
LEO is in direct line-of-sight communication with 
GEO-3 and the server on the LEO is transferring a 
file to the terrestrial client. The throughput in the 
forward direction, i.e., from the client transmitter to 
the LEO receiver via GEO-1 satellite and GEO-3 
satellite is shown in Figure 5(b). The LEO receiver 
has a higher throughput since it receives duplicate 
packets from the GEO-2 satellite. 



Figure 5-60 KB Files 


A similar set of results for 300 KB files is shown in 
Figure 6. 




The FTP response time, which is the end-to-end 
delay measured from the initiation of a request from 
the FTP application in the client to the completion of 
the file transfer, is shown in Figure 7 for 60 KB file 
transfers. There are two reasons for the periodic 
variation of this statistic. First, the round-trip 
propagation delay from the terrestrial client to the 
LEO server depends on the orbit of the LEO satellite 
and its position relative the satellites in the GEO 
constellation. This delay has a periodic behavior. 
Second, the end-to-end delay is dependent upon the 
queueing and processing delays at the server. This is 
a function of the file size and the frequency of the 
file transfers. The FTP response time for 60 KB files 
varies from 3 seconds to 6 seconds. Since the 
throughput for 60 KB files is low in comparison to 
the data rate of the channel (Figure 5), the large end- 
to-end delay is due to the slow server, i.e., the 
processing and queueing delays in the server. 





CONCLUSIONS 



Figures 8 and 9 show the FTP response time for 300 
KB and L5 MB files, respectively. As the file 
transfer size increases, the queueing and processing 
delays in the server lead to excessive end-to-end 
delays. 




In this paper a network comprised of a terrestrial 
site, a constellation of three GEO satellites, and a 
LEO satellite with orbital characteristics of the 
International Space Station was modeled and 
simulated. The communication in the network is 
based on TCP/IP over ATM with the ABR service 
category providing the QoS. The OSPF protocol was 
used for routing. We simulated FTP file transfers, 
with the terrestrial site serving as the client and the 
LEO satellite being the server. A comprehensive set 
of performance characteristics - throughput, end-to- 
end delay and server utilization - for a range of FTP 
file sizes were presented. When the file sizes 
increase, the end-to-end delays are quite large; this is 
due to the processing delay in the server. Since the 
orbital characteristics of the US Space Shuttle are 
similar to that of the International Space Station, we 
expect similar performance characteristics. 
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